home *** CD-ROM | disk | FTP | other *** search
/ SPACE 2 / SPACE - Library 2 - Volume 1.iso / program / 316 / install / projects < prev    next >
Encoding:
Text File  |  1988-10-20  |  6.6 KB  |  156 lines
  1. 1. Better optimization.
  2.  
  3. * More cse
  4.  
  5. The techniques for doing full global cse are described in the
  6. red dragon book.  It is likely to be slow and use a lot of memory,
  7. but it might be worth offering as an additional option.
  8.  
  9. It is probably possible to extend cse to a few very frequent cases
  10. without so much expense.
  11.  
  12. For example, it is not very hard to handle cse through if-then
  13. statements with no else clauses.  Here's how to do it.  On reaching a
  14. label, notice that the label's use-count is 1 and that the last
  15. preceding jump jumps conditionally to this label.  Now you know it
  16. is a simple if-then statement.  Remove from the hash table
  17. all the expressions that were entered since that jump insn
  18. and you can continue with cse.
  19.  
  20. It is probably not hard to handle cse from the end of a loop
  21. around to the beginning, and a few loops would be greatly sped
  22. up by this.
  23.  
  24. * Iteration variables and strength reduction.
  25.  
  26. The red dragon book describes standard techniques for these kinds
  27. of loop optimization.  But be careful!  These optimization techniques
  28. don't always make the code better.  You need to avoid performing
  29. the standard transformations unless they are greatly worth while.
  30.  
  31. In many common cases it is possible to deduce that an iteration
  32. variable is always positive during the loop.  This information
  33. may make it possible to use decrement-and-branch instructions
  34. whose branch conditions are inconvenient.  For example, the 68000
  35. `dbra' instruction branches if the value was not equal to zero.
  36. Therefore, it is not applicable to `for (i = 10; i >= 0; i--)'
  37. unless the compiler can know that I will never be negative
  38. before it is decremented.
  39.  
  40. * Using constraints on values.
  41.  
  42. Many operations could be simplified based on knowledge of the
  43. minimum and maximum possible values of a register at any particular time.
  44. These limits could come from the data types in the tree, via rtl generation,
  45. or they can be deduced from operations that are performed.  For example,
  46. the result of an `and' operation one of whose operands is 7 must be in
  47. the range 0 to 7.  Compare instructions also tell something about the
  48. possible values of the operand, in the code beyond the test.
  49.  
  50. Value constraints can be used to determine the results of a further
  51. comparison.  They can also indicate that certain `and' operations are
  52. redundant.  Constraints might permit a decrement and branch
  53. instruction that checks zeroness to be used when the user has
  54. specified to exit if negative.
  55.  
  56. * Smarter reload pass.
  57.  
  58. The reload pass as currently written can reload values only into registers
  59. that are reserved for reloading.  This means that in order to use a
  60. register for reloading it must spill everything out of that register.
  61.  
  62. It would be straightforward, though complicated, for reload1.c to keep
  63. track, during its scan, of which hard registers were available at each
  64. point in the function, and use for reloading even registers that were
  65. free only at the point they were needed.  This would avoid much spilling
  66. and make better code.
  67.  
  68. * Change the type of a variable.
  69.  
  70. Sometimes a variable is declared as `int', it is assigned only once
  71. from a value of type `char', and then it is used only by comparison
  72. against constants.  On many machines, better code would result if
  73. the variable had type `char'.  If the compiler could detect this
  74. case, it could change the declaration of the variable and change
  75. all the places that use it.
  76.  
  77. * Order of subexpressions.
  78.  
  79. It might be possible to make better code by paying attention
  80. to the order in which to generate code for subexpressions of an expression.
  81.  
  82. * Better code for switch statements.
  83.  
  84. If a switch statement has only a few cases, a sequence of conditional
  85. branches is generated for it, rather than a jump table.  It would
  86. be better to output a binary tree of branches.
  87.  
  88. * Distributive law.
  89.  
  90. The C expression *(X + 4 * (Y + C)) compiles better on certain
  91. machines if rewritten as *(X + 4*C + 4*Y) because of known addressing
  92. modes.  It may be tricky to determine when, and for which machines, to
  93. use each alternative.
  94.  
  95. * Jump-execute-next.
  96.  
  97. Many recent machines have jumps which optionally execute the following
  98. instruction before the instruction jumped to, either conditionally or
  99. unconditionally.  To take advantage of this capability requires a new
  100. compiler pass that would reorder instructions when possible.  After
  101. reload may be a good place for it.
  102.  
  103. On some machines, the result of a load from memory is not available
  104. until after the following instruction.  The easiest way to support
  105. these machines is to output each RTL load instruction as two assembler
  106. instructions, the second being a no-op.  Putting useful instructions
  107. after the load instructions may be a similar task to putting them
  108. after jump instructions.
  109.  
  110. * Pipeline scheduling.
  111.  
  112. On many machines, code gets faster if instructions are reordered
  113. so that pipelines are kept full.  Doing the best possible job of this
  114. requires knowing which functional units each kind of instruction executes
  115. in and how long the functional unit stays busy with it.  Then the
  116. goal is to reorder the instructions to keep many functional units
  117. busy but never feed them so fast they must wait.
  118.  
  119. 2. Simpler porting.
  120.  
  121. Right now, describing the target machine's instructions is done
  122. cleanly, but describing its addressing mode is done with several
  123. ad-hoc macro definitions.  Porting would be much easier if there were
  124. an RTL description for addressing modes like that for instructions.
  125. Tools analogous to genflags and genrecog would generate macros from
  126. this description.
  127.  
  128. There would be one pattern in the address-description file for each
  129. kind of addressing, and this pattern would have:
  130.  
  131.   * the RTL expression for the address
  132.   * C code to verify its validity (since that may depend on
  133.     the exact data).
  134.   * C code to print the address in assembler language.
  135.   * C code to convert the address into a valid one, if it is not valid.
  136.     (This would replace LEGITIMIZE_ADDRESS).
  137.   * Register constraints for all indeterminates that appear
  138.     in the RTL expression.
  139.  
  140. 3. Other languages.
  141.  
  142. Front ends for Pascal, Fortran, Algol, Cobol, Modula-2 and Ada are
  143. desirable.
  144.  
  145. Pascal, Modula-2 and Ada require the implementation of functions
  146. within functions.  Some of the mechanisms for this already exist.
  147.  
  148. 4. Generalize the machine model.
  149.  
  150. Some new compiler features may be needed to do a good job on machines
  151. where static data needs to be addressed using base registers.
  152.  
  153. Some machines have two stacks in different areas of memory, one used
  154. for scalars and another for large objects.  The compiler does not
  155. now have a way to understand this.
  156.